home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19971216-19980424
/
000141_news@newsmaster….columbia.edu _Sat Jan 31 10:16:32 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
6KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA04912
for <kermit.misc@watsun.cc.columbia.edu>; Sat, 31 Jan 1998 10:16:32 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA23644
for kermit.misc@watsun; Sat, 31 Jan 1998 10:16:31 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Expect and Kermit (was: Re: frequent timeouts!)
Date: 31 Jan 1998 15:16:29 GMT
Organization: Columbia University
Lines: 102
Message-ID: <6avf8d$hmd$1@apakabar.cc.columbia.edu>
References: <6ao98e$p4h$1@apakabar.cc.columbia.edu> <gerlachEnIuIF.K4L@netcom.com> <6aonud$42r$1@apakabar.cc.columbia.edu> <gerlachEnK1G9.IBG@netcom.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8324
In article <gerlachEnK1G9.IBG@netcom.com>,
Matthew H. Gerlach <gerlach@netcom.com> wrote:
: In article <6aonud$42r$1@apakabar.cc.columbia.edu>
: fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
: >In article <gerlachEnIuIF.K4L@netcom.com>,
: >Matthew H. Gerlach <gerlach@netcom.com> wrote:
: >: The kermit scripting language is a greate thing, most notably the fact
: >: that kermit scripts will run on many platforms. That being said I find
: >: it very beneficial to control C-Kermit from Expect, and I work for a
: >: company that does a lot of it. The main benefit is that one might need
: >: to write a script that controls many serial connections in conjuction
: >: with many connections to regular UNIX programs. This appears to be
: >: easier with Expect.
: >:
: >Some concrete examples might be instructive.
:
: Since I am a consultant for the company I mention above, I can't show code,
: but I will try to explain what they do. In short they have a UNIX box
: that performs automated telephony testing. This testing involves two
: separate pieces. One piece controls the end user's telephony equipment
: via a serial port. The other piece is the actual voice frequency testing
: involved with DSP's. The interface to voice frequency testing is an
: interactive program. So the scripts usualy send some commands to the
: telephone equipment, and once it is all set up, some commands get sent
: to the voice testing program. So the Expect scripts coordinates the serial
: stuff with the DSP stuff.
:
And of course a Kermit script can do that too, and more portably (since
Kermit runs more places that Expect does), and without the problems inherent
in interfacing two programs to do what one could do.
(For those who haven't been keeping up with recent Kermit releases, the
Kermit script language is much more powerful than it was a few years ago.)
: At this point it is probably worth noting, that the company I mention was
: too cheap to pay for kermit to put on released product; so it "talks" to cu.
: However, in house we tend to use kermit, because it's easier to use and has
: the wonderful "log session" feature. I use kermit exclusively just because
: it is a great piece of software that is also well documented. I own copies
: of both revs of the book.
:
Thanks.
: Yes this is a very useful dialog, because we are discussing interesting
: ways to use kermit :) As you say Expect is basically a screen-scaper.
: For those who are interested, Expect is an extension to the TCL scripting
: language. The Expect extention simply spawns the desired program and
: opens a pseudo-tty to the STDIN/STDOUT of the child, in this case Kermit.
: The TCL scripting language does have the usual IF-ELSE, FOR and WHILE,
: subroutines and stuff.
:
Of course lots of languages have these features. The salient question is:
do they also have the built-in serial and networking i/o capabilities?
The expect command itself looks an awful lot like
: the use of minput followed by a switch. As you point, however,
: the kermit commands return a status that can be tested by
: IF SUCCESS/FAILURE. This information does not appear to be available to
: Expect unless there is a kermit command like "print status of last command".
: Is that a feature request?
:
If you REALLY want to control Kermit with Expect or Tcl or Perl, then yes,
you can tell Kermit to "show status" after each and every command, and then
look for the word SUCCESS or FAILURE. I think a program that does this will
start to look pretty silly, compared to how it would look as a native Kermit
program.
: At this point I would like by throwing out yet another scripting
: language, Perl. One can do the same thing in Perl as one does with
: Expect, and that is what I personally do because I find Perl to be
: a much more powerful programming language. Another interesting point
: is that a common question to the perl news group is "how do I control
: a serial port from perl"? Well, I always tell them, have Perl "talk"
: to kermit! I think now I will tell them, have perl talk to kermit scripts.
:
And then the next step is to remove Perl from the equation and do it all in
Kermit :-)� Because you didn't need Perl (or Tcl or Expect) in the first
place, except if you wanted to layer a curses or GUI interface over your
script Kermit (and yes, that's yet another item that's on our long, long,
long list).
Again, just so it's clear: Kermit scripts are portable among:
. Windows 95, 98, and NT
. UNIX - *all* varieties (hundreds of them, not just the big names)
. UNIX relatives like OS-9, QNX, Plan 9, BeBox BeOS, etc.
. DEC (Compaq) VMS (OpenVMS)
. OS/2
. Stratus VOS
. AOS/VS and AOS/VS-II
And also (with a little care) to:
. DOS
. Windows 3.x
And to any other platform that C-Kermit will be ported to in the future.
They work not only over serial connections, but in most cases also TCP/IP
Telnet or Rlogin (or any other TCP service), and in some cases also X.25,
NETBIOS, DECnet (LAT or CTERM), and various other networking methods.
- Frank